From @ysth

Created by @ysth

exiting an eval BLOCK via last when there is no loop block there
sends control to the wrong place​:

This is correct​:

$ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";'
Exiting eval via last at -e line 1.
14

This should print only "1" and give the​: Can't "last" outside a loop block
warning​:

$ perl -we'eval { print "1"; last; print "2" }; print "3"'
Exiting eval via last at -e line 1.
13

This is also correct​:

$ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";'
Exiting eval via last at -e line 1.
14

The following is just plain weird. Once it's printed "3", why is it then
"Exiting subroutine via last"? It should give both warnings plus the
Can't "last" outside a loop block warning, and only print "1"​:

$ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} foo;
print "4";'
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
134

All behavior consistent on 5.6.2, 5.8.[1234], 5.9.[01], and bleadperl.

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.2:

Configured by Gerrit at Fri Nov  7 12:03:56     2003.

Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
  Platform:
    osname=cygwin, osvers=1.5.5(0.9432), archname=cygwin-thread-multi-64int
    uname='cygwin_nt-5.0 troubardix 1.5.5(0.9432) 2003-09-20 16:31 i686 unknown unknown cygwin '
    config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads -Doptimize=-O2 -Dman3ext=3pm'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=undef
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing',
    optimize='-O2',
    cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing'
    ccversion='', gccversion='3.3.1 (cygming special)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='ld2', ldflags =' -s -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -ldb -lcrypt -lgdbm_compat
    perllibs=-lcrypt -lgdbm_compat
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
    cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.2:
    /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int
    /usr/lib/perl5/5.8.2
    /usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int
    /usr/lib/perl5/site_perl/5.8.2
    /usr/lib/perl5/site_perl
    .


Environment for perl v5.8.2:
    CYGWIN=tty ntsec title server
    HOME=/home/sthoenna
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/bin:/usr/local/bin:/bin:/usr/X11R6/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/Common Files/Adaptec Shared/System:/cygdrive/c/Program Files/Rational/common
    PERL_BADLANG (unset)
    SHELL (unset)

From @ysth

On Wed, Apr 28, 2004 at 04​:17​:12PM -0700, sthoenna@​efn.org wrote​:

This is also correct​:

$ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";'
Exiting eval via last at -e line 1.
14

Err, that was supposed to be this​:

$ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} { foo; } p
rint "4";'
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
14

From @iabyn

On Wed, Apr 28, 2004 at 11​:17​:43PM -0000, Yitzchak Scott-Thoennes wrote​:

exiting an eval BLOCK via last when there is no loop block there
sends control to the wrong place​:

This is correct​:

$ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";'
Exiting eval via last at -e line 1.
14

[snip]

This is also correct​:

$ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";'
Exiting eval via last at -e line 1.
14

They both look identical to me?

The following is just plain weird. Once it's printed "3", why is it then
"Exiting subroutine via last"? It should give both warnings plus the
Can't "last" outside a loop block warning, and only print "1"​:

$ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} foo;
print "4";'
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
134

The eval { } is trapping the fatal error C<Can't "last" outside a loop block>

Although frankly I think that last-ing out of a sub should be a fatal
error too rather than just a warning; otherwise you get the following
spooky action at a distance​:

$ ./perl -wle' sub f { redo if $_[0] > 2 } for (1..5) { print $_; f($_) }'
1
2
3
Exiting subroutine via redo at -e line 1.
3
Exiting subroutine via redo at -e line 1.
3
Exiting subroutine via redo at -e line 1.
3
...

ie you can control the loop that calls the sub from within the sub!

--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
  -- Things That Never Happen in "Star Trek" #19

The RT System itself - Status changed from 'new' to 'open'

From @ysth

On Mon, 3 May 2004, Dave Mitchell wrote​:

On Wed, Apr 28, 2004 at 11​:17​:43PM -0000, Yitzchak Scott-Thoennes wrote​:

This is correct​:
...
This is also correct​:

$ perl -we'{eval { print "1"; last; print "2" }; print "3"} print "4";'
Exiting eval via last at -e line 1.
14

They both look identical to me?

I posted a response with the correct second correct case; something like​:
sub foo { eval { print "1"; last; print "2" }; print "3"} { foo } print "4"

printing "14"

The following is just plain weird. Once it's printed "3", why is it then
"Exiting subroutine via last"? It should give both warnings plus the
Can't "last" outside a loop block warning, and only print "1"​:

$ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} foo;
print "4";'
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
134

The eval { } is trapping the fatal error C<Can't "last" outside a loop block>

Why is that fatal in an eval but not in a sub? (Relying on my memory here;
I'll actually try it when I have a perl to try it with).

Although frankly I think that last-ing out of a sub should be a fatal
error too rather than just a warning; otherwise you get the following
spooky action at a distance​:

$ ./perl -wle' sub f { redo if $_[0] > 2 } for (1..5) { print $_; f($_) }'
1
2
3
Exiting subroutine via redo at -e line 1.
3
Exiting subroutine via redo at -e line 1.
3
Exiting subroutine via redo at -e line 1.
3
...

ie you can control the loop that calls the sub from within the sub!

That's the intent; IIRC, the warning was added later when it was realized
that wasn't such a hot idea. You can't just remove this behavior without
a deprecation cycle; even though it has warned for a long time, warning ne
deprecation.

From @iabyn

On Mon, May 03, 2004 at 08​:36​:05AM -0700, Yitzchak Scott-Thoennes wrote​:

On Mon, 3 May 2004, Dave Mitchell wrote​:

The following is just plain weird. Once it's printed "3", why is it then
"Exiting subroutine via last"? It should give both warnings plus the
Can't "last" outside a loop block warning, and only print "1"​:

$ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} foo;
print "4";'
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
134

The eval { } is trapping the fatal error C<Can't "last" outside a loop block>

Why is that fatal in an eval but not in a sub? (Relying on my memory here;
I'll actually try it when I have a perl to try it with).

It's still fatal​:

$ ./perl -wle'sub foo { print "1"; last; print "2" } foo; print "4";'
1
Exiting subroutine via last at -e line 1.
Can't "last" outside a loop block at -e line 1.

ie you can control the loop that calls the sub from within the sub!

That's the intent; IIRC, the warning was added later when it was realized
that wasn't such a hot idea. You can't just remove this behavior without
a deprecation cycle; even though it has warned for a long time, warning ne
deprecation.

The warning's been there since at least 5.000. There's no mention in
perldiag that it's deprecated :-(

--
"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."

From @ysth

On Mon, May 03, 2004 at 04​:23​:04PM +0100, Dave Mitchell <davem@​iabyn.com> wrote​:

The following is just plain weird. Once it's printed "3", why is it then
"Exiting subroutine via last"? It should give both warnings plus the
Can't "last" outside a loop block warning, and only print "1"​:

$ perl -we'sub foo { eval { print "1"; last; print "2" }; print "3"} foo;
print "4";'
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
134

The eval { } is trapping the fatal error C<Can't "last" outside a loop block>

Ok, that makes sense; I overlooked that as a possibility because of the
"Exiting subroutine" warning.

So, the only bug here is the bogus "Exiting subroutine via last" warning.
Note that it appears for each outer eval/sub​:

$ perl -wle'sub {sub {eval { eval { eval { last }; print "not really exiting this eval"}; print "or this one either" }; print "not really exiting this sub"}->(); print "or this one either"}->()'
Exiting eval via last at -e line 1.
Exiting eval via last at -e line 1.
Exiting eval via last at -e line 1.
Exiting subroutine via last at -e line 1.
Exiting subroutine via last at -e line 1.
not really exiting this eval
or this one either
not really exiting this sub
or this one either

From @iabyn

On Mon, May 03, 2004 at 10​:35​:38AM -0700, Yitzchak Scott-Thoennes wrote​:

So, the only bug here is the bogus "Exiting subroutine via last" warning.
Note that it appears for each outer eval/sub​:

That would be quite hard to fix efficiently. The current algorithm
is to scan back through the context stack looking for a loop context,
warning along the way of any sub/eval etc contexts. If it gets to the
bottom of the stack and hasn't found a loop, it then raises an exception.
If this is trapped by an eval, the spurious warnings have already been
issued. To avoid this, then context stack would have to be scanned twice,
the first time with warnings suppressed.

A lot easirt approach would be to stop or die when a sub/eval context is
encountered.

Does anyone have any enthusiasm for any of the following (in order of
increasing severity)​:

1. making 'Exiting subroutine/eval/etc via last/redo/etc'
offically a deprecated warning

2. making the warning mandatory

3. making it stop at the first sub/eval it finds, ie

sub f { last } becomes equivalent to sub f { return } (but with
a runtime warning) - in contrast to the current behaviour, where
for (1..3) { f() } stops after the first iteration, but
f() dies with 'Can't "last" outside a loop block'

4. making it die at the first sub/eval it finds, ie upgrading the current
warning to a fatal error.

Dave.

--
In my day, we used to edit the inodes by hand. With magnets.

From @davidnicol

Dave Mitchell wrote​:

Does anyone have any enthusiasm for any of the following (in order of
increasing severity)​:

I think the system is fine the way it is. If your program has
an endless loop because of a free "redo" in a
subroutine, running with warnings on will reveal the situation
right quick.

If we really must do something about this non-issue (besides
documenting the edge cases until our fingers fall off,)
the people who are
so jumpy about action at a distance might enjoy having another
"strict" mode, perhaps

  use strict flow

that would make (next, redo, last) in subroutines fatal. Gripes about
certain uses of "goto" could get barred with this pragma also.

No, I do not know how many lines the patch would touch, I
imagine hundreds.

--
davidnicol@​pay2send.com.
I know you, junk mail. Gonna miss you when you're gone

From rick@bort.ca

On Tue, May 04, 2004 at 06​:19​:06PM -0500, David Nicol wrote​:

If we really must do something about this non-issue (besides
documenting the edge cases until our fingers fall off,)
the people who are
so jumpy about action at a distance might enjoy having another
"strict" mode, perhaps

use strict flow

that would make (next, redo, last) in subroutines fatal. Gripes about
certain uses of "goto" could get barred with this pragma also.

We already have this.

  use warnings FATAL => 'exiting';

--
Rick Delaney
rick@​bort.ca

From @hvds

Dave Mitchell <davem@​iabyn.com> wrote​:
:On Mon, May 03, 2004 at 10​:35​:38AM -0700, Yitzchak Scott-Thoennes wrote​:
:> So, the only bug here is the bogus "Exiting subroutine via last" warning.
:> Note that it appears for each outer eval/sub​:
:
:That would be quite hard to fix efficiently. The current algorithm
:is to scan back through the context stack looking for a loop context,
:warning along the way of any sub/eval etc contexts. If it gets to the
:bottom of the stack and hasn't found a loop, it then raises an exception.
:If this is trapped by an eval, the spurious warnings have already been
:issued. To avoid this, then context stack would have to be scanned twice,
:the first time with warnings suppressed.
:
:A lot easirt approach would be to stop or die when a sub/eval context is
:encountered.

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Eval is a different beast though - my gut shrinks far more from
'exiting eval' without failure than from 'exiting sub'; I always expect
control to return to eval, and nothing to bypass it. And if 'exiting eval'
were fatal it could be simpler​: we could actually unwind as we go,
rather than having to do a full context stack scan before deciding
what to do.

Even so I'm not convinced it should be changed at all. And if not,
we are left with the bogus warnings. Am I right that when we get the
bogus warnings there is always at least one correct warning issued?
If so I'd be happy just to document it if it isn't practical to fix​:
anyone being bitten by this would presumably either fix their code
or add a 'no warnings qw/ exiting /', and either way both real and
bogus warnings would disappear.

Hugo

From @iabyn

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

Even so I'm not convinced it should be changed at all. And if not,
we are left with the bogus warnings. Am I right that when we get the
bogus warnings there is always at least one correct warning issued?

Yes.

  eval {last}

will give a warning about leaving eval via last, then similar warnings
for any outer contexts, then, if no loop context is found, dies
with 'no loop found', which is then trapped by the eval.
So the first warning could be argued as being correct.

--
Counsellor Troi states something other than the blindingly obvious.
  -- Things That Never Happen in "Star Trek" #16

From @iabyn

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Just so we're clear on this - the current behaviour not only causes an exit
from the sub, but then applies the 'last' or 'redo' or whatever to the
loop (if any) that (possibly indirectly) called that sub. You're happy
with that?

--
In my day, we used to edit the inodes by hand. With magnets.

From jcromie@divsol.com

Dave Mitchell wrote​:

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Just so we're clear on this - the current behaviour not only causes an exit
from the sub, but then applies the 'last' or 'redo' or whatever to the
loop (if any) that (possibly indirectly) called that sub. You're happy
with that?

sorry i havent kept up here, but could this be explicitly enabled
with a pragma ?

While this magic could be great for some funky jump table constructs
(leap tables ?),
it seems like pouring out your old anti-freeze near your neighbors dog.

jimc

From @davidnicol

Dave Mitchell wrote​:

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Just so we're clear on this - the current behaviour not only causes an exit
from the sub, but then applies the 'last' or 'redo' or whatever to the
loop (if any) that (possibly indirectly) called that sub. You're happy
with that?

it seems to me that the power of this construct is similar to
the ability to exit out of a subroutine with a goto. Perl's
back yard is not to be traipsed around in bare-footed.

--
davidnicol@​pay2send.com.
I know you, junk mail. Gonna miss you when you're gone

From @timbunce

On Fri, May 07, 2004 at 08​:17​:29PM +0100, Dave Mitchell wrote​:

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Just so we're clear on this - the current behaviour not only causes an exit
from the sub, but then applies the 'last' or 'redo' or whatever to the
loop (if any) that (possibly indirectly) called that sub. You're happy
with that?

Isn't that exactly what skip() does in Test​::More?

  SKIP​: {
  ok(...);
  ok(...);
  skip "Can't foo", 2 unless $foo;
  ok(...);
  ok(...);
  }

http​://search.cpan.org/~mschwern/Test-Simple-0.47/lib/Test/More.pm#Conditional_tests

http​://search.cpan.org/src/MSCHWERN/Test-Simple-0.47/lib/Test/More.pm

  sub skip {
  my($why, $how_many) = @​_;
  ...
  local $^W = 0;
  last SKIP;
  }

This is very widely used.

Tim [who hasn't been following this thread]

From @iabyn

On Fri, May 07, 2004 at 10​:39​:53PM +0100, Tim Bunce wrote​:

On Fri, May 07, 2004 at 08​:17​:29PM +0100, Dave Mitchell wrote​:

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Just so we're clear on this - the current behaviour not only causes an exit
from the sub, but then applies the 'last' or 'redo' or whatever to the
loop (if any) that (possibly indirectly) called that sub. You're happy
with that?

Isn't that exactly what skip() does in Test​::More?

Ah, so it does. Scary!

--
Counsellor Troi states something other than the blindingly obvious.
  -- Things That Never Happen in "Star Trek" #16

From @hvds

Dave Mitchell <davem@​iabyn.com> wrote​:
:On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:
:> I would say that 'exiting subroutine via <control>' is a dangerous but
:> useful thing to be able to do. I don't think it should be deprecated.
:
:Just so we're clear on this - the current behaviour not only causes an exit
:from the sub, but then applies the 'last' or 'redo' or whatever to the
:loop (if any) that (possibly indirectly) called that sub. You're happy
:with that?

I can never entirely decide whether I'm happy about it, but it isn't
going to be changing any time soon.

As well as the SKIP functionality pointed out by Tim, note that
Apocalypse 12 also commits perl6 to supporting this as standard by
defining method lookup strategies to do exactly this with 'next METHOD'
and 'last METHOD'.

Hugo

From @ysth

On Sun, May 09, 2004 at 03​:27​:25PM -0000, Hugo van der Sanden via RT <perlbug-followup@​perl.org> wrote​:

Dave Mitchell <davem@​iabyn.com> wrote​:
:On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:
:> I would say that 'exiting subroutine via <control>' is a dangerous but
:> useful thing to be able to do. I don't think it should be deprecated.
:
:Just so we're clear on this - the current behaviour not only causes an exit
:from the sub, but then applies the 'last' or 'redo' or whatever to the
:loop (if any) that (possibly indirectly) called that sub. You're happy
:with that?

I can never entirely decide whether I'm happy about it, but it isn't
going to be changing any time soon.

As well as the SKIP functionality pointed out by Tim, note that
Apocalypse 12 also commits perl6 to supporting this as standard by
defining method lookup strategies to do exactly this with 'next METHOD'
and 'last METHOD'.

It seems fairly analogous to C's longjmp()...something you don't want to
have to use, but nice to have around when do you have to use it.

From @Tux

On Sat 08 May 2004 00​:22, Dave Mitchell <davem@​iabyn.com> wrote​:

On Fri, May 07, 2004 at 10​:39​:53PM +0100, Tim Bunce wrote​:

On Fri, May 07, 2004 at 08​:17​:29PM +0100, Dave Mitchell wrote​:

On Wed, May 05, 2004 at 12​:34​:14PM +0100, hv@​crypt.org wrote​:

I would say that 'exiting subroutine via <control>' is a dangerous but
useful thing to be able to do. I don't think it should be deprecated.

Just so we're clear on this - the current behaviour not only causes an exit
from the sub, but then applies the 'last' or 'redo' or whatever to the
loop (if any) that (possibly indirectly) called that sub. You're happy
with that?

Isn't that exactly what skip() does in Test​::More?

Ah, so it does. Scary!

But in this case it uses an explicit label.

A warning might be in place if no label is passed.

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
  AIX 4.3, SuSE 9.0, and Win2k. http​://www.cmve.net/~merijn/
http​://archives.develooper.com/daily-build@​perl.org/ perl-qa@​perl.org
send smoke reports to​: smokers-reports@​perl.org, QA​: http​://qa.perl.org

From @iabyn

On Mon, May 10, 2004 at 08​:59​:44AM +0200, H.Merijn Brand wrote​:

But in this case it uses an explicit label.

A warning might be in place if no label is passed.

A warning is generated anyway, label or no label.

--
There's a traditional definition of a shyster​: a lawyer who, when the law
is against him, pounds on the facts; when the facts are against him,
pounds on the law; and when both the facts and the law are against him,
pounds on the table.
  -- Eben Moglen referring to SCO

From @davidnicol

hv@​crypt.org wrote​:

Apocalypse 12 also commits perl6 to supporting this as standard by
defining method lookup strategies to do exactly this with 'next METHOD'
and 'last METHOD'.

Hugo

There is a lot of perl6 that seems to me would make a better
"approved best practice" document than a language rewriting.

--
davidnicol@​pay2send.com.
I know you, junk mail. Gonna miss you when you're gone

From @cpansprout

There is no way this behaviour is going to change now. Too much code
uses it. (In fact, I sometimes use it in callback routines to bypass
exception-handling in the module the callback is passed to.)

I think the warning about exiting via last when last ends up dying
should still stay, as such a construct, without an explicit ‘no warnings
'exiting'’, is probably a bug.

I’m marking this as rejected and ‘wontfix’ unless someone convinces me
otherwise.

@cpansprout - Status changed from 'open' to 'rejected'